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GAMING NETWORK ENVIRONMENT PROVIDING A CASHLESS GAMING 

SERVICE 

Cross-reference to Related Applications 
This application claims the benefit of United States Provisional Patent Application 
serial no. 60/480,929 entitled "CASHLESS GAMING SERVICE IN A SERVICE- 
• ORIENTED GAMING NETWORK ENVIRONMENT", filed June 23, 2003; and is 

» 

related to United States Patent Application serial no. 10/788,903, entitled "A SERVICE- 
ORIENTED GAMING NETWORK ENVIRONMENT", (Attorney Docket 
1842.020US1), filed on February 26, 2004 and assigned to the same assignee as the 
present application; each of which are hereby incorporated by reference herein for all 
purposes. 

Field 

The present invention relates generally to software and hardware systems for 
gaming machines and gaming machine networks, and more particularly to providing a 
cashless gaming service in a service-oriented gaining network environment. 

Background 

Today's gaming terminal typically comprises a computerized system controlling a 
video display or reels that provide wagering games such as video and mechanical slots, 
video card games (poker, blackjack etc.), video keno, video bingo, video pachinko and 
other games typical in the gaming industry. In addition, support computing systems such 
as accounting, player tracking and other "back office" systems exist in order to provide 
support for a gaming environment. 

In order to prevent players from becoming bored, new versions of wagering games, 
and alterations to existing games are constantly being developed. In the past, the game 
software and content for gaming terminals and back office systems have been developed 
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using proprietary or closed hardware, operating systems, application development systems, 
and communications systems. Sometimes these systems are provided by a single vendor. 

Additionally, gaming machines typically require a means to accept funds in order 
to make wagers during the game, hi previous systems, gaming machines provide coin, 

5 token and bill acceptors and ticket readers in order to accept funds. However, this can be 
inconvenient to the player because the player must carry coins, tokens, bills or tickets in 
order to use the gaming machine. Unfortunately, due to the proprietary and closed nature 
of existing architectures, it can be difficult to develop new games, and it is difficult to 
modify existing proprietary game architectures to include support for cashless gaming. As 

10 a result, the cost and time associated with updating and adding new games or modifying 
existing games in gaming networks is relatively high. 

In view of the above-mentioned problems and concerns, there is a need in the art 
for the present invention. 

Summary 

15 The above-mentioned shortcomings, disadvantages and problems are addressed by 

the present invention, which will be understood by reading and studying the following 
specification. 

One aspect of the systems and methods relates to providing a cashless gaming 
service in a gaming network. The gaming network may comprise gaining machines, 

20 service providers, and other entities. The cashless gaming service may provide a web 
based service for transferring funds in and out of a user account with a gaming 
establishment. The entities participating in the gaming network may implement a Gaming 
Services Framework using the World Wide Web and internetworking technology. The 
World Wide Web ("Web" from here on) is a networked information system comprising 

25 agents (clients, servers, and other programs) that exchange information. The Web and 
networking architecture is the set of rules that agents in the system follow, resulting in a 
shared information space that scales well and behaves predictably. 

The Gaming Services Framework comprises a set of services, protocols, XML 
schemas, and methods for providing secure gaming system functionality in a distributed, 
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network based architecture. It is intended to be a service-oriented framework for gaming 
and property management based upon internetworking technology and web services 
concepts. Specifically, it supports a loosely coupled architecture that consists of software 
components that semantically encapsulate discrete functionality (self contained and 
5 perform a single function or a related group of functions — the component describes its 
own inputs and outputs in a way that other software can determine what it does, how to 
invoke its functionality, and what result to expect). These components are distributed and 
programmatically accessible (called by and exchange data with other software) over 
standard internetworking protocols (TCP/IP, HTTP, DNS, DHCP, etc.). 
10 The present invention describes systems, methods, and computer-readable media 

■ 

of varying scope. In addition to the aspects and advantages of the present invention 
described in this summary, further aspects and advantages of the invention will become 
apparent by reference to the drawings and by reading the detailed description that follows. 

* 

Brief Description Of The Drawings 

15 FIG. 1 is a perspective view of an exemplary gaming machine incorporated in the present 

* 

invention. 

FIG. 2 is a block diagram providing an example of a service-oriented network for 

distributed management in a gaming environment. 
FIG. 3 is a block diagram providing general description of service-oriented discovery and 
20 interaction. » 

FIG. 4 is a representation of a Gaming Services Protocol Stack according to embodiments 

of the invention. 

FIGs. 5A, 5B and 6 are flow diagrams illustrating methods and message flow for a 
cashless gaming service according to embodiments of the invention. 
25 Detailed Description 

In the following detailed description of exemplary embodiments of the invention, 
reference is made to the accompanying drawings which form a part hereof, and in which is 
shown by way of illustration specific exemplary embodiments in which the invention may 
be practiced. These embodiments are described in sufficient detail to enable those skilled 
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in the art to practice the invention, and it is to be understood that other embodiments may 
be utilized and that logical, mechanical, electrical and other changes may be made without 
departing from the scope of the present invention. 

Some portions of the detailed descriptions which follow are presented in terms of 
5 algorithms and symbolic representations of operations on data bits within a computer 
memory. These algorithmic descriptions and representations are the ways used by those 
skilled in the data processing arts to most effectively convey the substance of their work to 
others skilled in the art. An algorithm is here, and generally, conceived to be a self- 
consistent sequence of steps leading to a desired result. The steps are those requiring 

1 0 physical manipulations of physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals capable of being stored, 
transferred, combined, compared, and otherwise manipulated. It has proven convenient at 
times, principally for reasons of common usage, to refer to these signals as bits, values, 
elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, 

15 however, that all of these and similar terms are to be associated with the appropriate 
physical quantities and are merely convenient labels applied to these quantities. Unless 
specifically stated otherwise as apparent from the following discussions, terms such as 
"processing" or "computing" or "calculating" or "determining" or "displaying" or the like, 
refer to the action and processes of a computer system, or similar computing device, that 

20 manipulates and transforms data represented as physical (e.g., electronic) quantities within 
the computer system's registers and memories into other data similarly represented as 
physical quantities within the computer system memories or registers or other such 
information storage, transmission or display devices. 

In the Figures, the same reference number is used throughout to refer to an 

25 identical component which appears in multiple Figures. Signals and connections may be 
referred to by the same reference number or label, and the actual meaning will be clear 
from its use in the context of the description. 

The description of the various embodiments is to be construed as exemplary only 
and does not describe every possible instance of the invention. Numerous alternatives 
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could be implemented, using combinations of current or future technologies, which would 
still fall within the scope of the claims. The present invention is directed to a cashless 
gaming service in a service-oriented framework for gaming networks that allows for the 
interoperability of the software components (regardless of manufacturer, operating system, 
5 or application) reducing the dependence on a closed-system, single vendor solutions and 
allowing for variety in innovation and competition. 

The following detailed description is, therefore, not to be taken in a limiting sense, 
and the scope of the present invention is defined only by the appended claims. 

Operating Environment 

1 0 FIG. 1 illustrates an exemplary gaming machine 1 0 in which embodiments of the 

invention maybe implemented. In some embodiments, gaming machine 10 is operable to 
conduct a wagering game. These wagering games may include reel based games such as 
video or mechanical slot machine games, card based games such as video poker, video 
dice games (e.g. a Yahtzee® like dice game) or other types of wagering games typical in 

15 the gaming industry. If based in video, the gaming machine 10 includes a video display 12 
such as a cathode ray tube (CRT), liquid crystal display (LCD), plasma, or other type of 
video display known in the art. A touch screen preferably overlies the display 12. In the 
illustrated embodiment, the gaming machine 10 is an "upright" version in which the 
display 12 is oriented vertically relative to a player. Alternatively, the gaming machine 

20 may be a "slant-top" version in which the display 12 is slanted at about a thirty-degree 
angle toward the player. 

The gaming machine 10 includes a plurality of possible credit receiving 
mechanisms 14 for receiving credits to be used for placing wagers in the game. The credit 
receiving mechanisms 14 may, for example, include a coin acceptor, a bill acceptor, a 

25 ticket reader, and a card reader. The bill acceptor and the ticket reader may be combined 
into a single unit. The card reader may, for example, accept magnetic cards and smart 
(chip) cards coded with money or designating an account containing money. 

In some embodiments, the gaming machine 10 includes a user interface comprising 
a plurality of push-buttons 16, the above-noted touch screen, and other possible devices. 

5 
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The plurality of push-buttons 16 may, for example, include one or more ,r bet" buttons for 
wagering, a "play" button for commencing play, a "collect" button for cashing out, a help" 
button for viewing a help screen, a "pay table" button for viewing the pay table(s), and a 
"call attendant" button for calling an attendant. Additional game specific buttons may be 
5 provided to facilitate play of the specific game executed on the machine. The touch screen 
may define touch keys for implementing many of the same functions as the push-buttons. 
Additionally, in the case of video poker, the touch screen may implement a card 
identification function to indicate which cards a player desires to keep for the next round. 
Other possible user interface devices include a keyboard and a pointing device such as a 

10 mouse or trackball. 

A processor controls operation of the gaming machine 10. In response to receiving 
a wager and a command to initiate play, the processor randomly selects a game outcome 
from a plurality of possible outcomes and causes the display 12 to depict indicia 
representative of the selected game outcome. In the case of slots for example mechanical 

15 or simulated slot reels are rotated and stopped to place symbols on the reels in visual 
association with one or more pay lines. If the selected outcome is one of the winning 
outcomes defined by a pay table, the processor awards the player with a number of credits 
associated with the winning outcome. 

FIG. 2 illustrates an example of a Gaming Service Network 210 comprising a 

20 customer data center 218 and a customer property 216. The data center 218 and customer 

property 216 are connected via a network 220. In some embodiments, network 220 is a 

> 

public network such as the Internet. However, in alternative embodiments, private 
networks, including corporate intranets or extranets may be used to connect a data center 
218 with one or more properties 216. 
25 In some embodiments, the Customer Corporate Data Center 218 contains the bulk 

of the network servers supporting gaming properties owned by the corporation. Major 
elements of the gaming service network include Auth server 232, Gaming Management 
Server 236, and Progressive Server 238. hi some embodiments, Auth Server 32 provides 
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authentication, authorization and content integrity for client devices attempting to interact 
with other servers and services in the architecture. 

In some embodiments, the Gaming Management Server 236 includes the following 
services: Boot Service, Name Service, Time Service, Game Management Service, Game 
5 Update Service, Event Management Service, Accounting Service, and Discovery Service. 

In some embodiments, the Progressive Server 238 hosts a value-add service that 
allows a gaming machine to participate within a progressive gaming offering. Any value- 
add service can be added or substituted for this server/service. A progressive game 
offering is provided as an example. Other value-add services can be distributed on existing 
1 0 servers or reside on a newly added server. 

The Customer Property 16' contains gaming machines 10, which in some 
embodiments allow remote updates and configuration through a network interface on the 
gaming machine. In some embodiments, a Boot Server 234 contains a DHCP service that 
facilitates the distribution of IP addressing to the gaming machines 10. It should be noted 
15 that any device capable of supporting a wagering game could be substituted for gaming 
machine 10, For example, a personal or laptop computer executing a wagering game may 
participate in the gaming network using the services described below. 

As noted above, various services may be located throughout the gaming network. 
In some embodiments of the invention, a set of core operational services may include one 
20 or more of the following services: 

Boot Service Provides dynamic IP addressing to devices upon boot 

(start-up). Typically supported by Dynamic Host 
Configuration Protocol (DHCP). 

Discovery Service Provides the address information of the server containing 

25 the service when prompted by the requestor as well as the 

service description, binding and location on the server. 

• 

Authentication Service Contains the master Authentication Database. 

Authenticates the service user before allowing the use of 
services in the Gaming Services Framework. 
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Authorization Service 



25 



30 



Contains the master Authorization Database. Authorizes 
the use of services in the Gaming Services Framework by 
a service requestor. 



Gaming Management Service Provides the ability to configure and monitor gaming 
5 machines and other services from a central location. 

Name Service Provides name resolution service to enable machines in a 

gaming network to refer to each other by name instead of 
an IP Address. In some embodiments the name service is 
implemented in part using the Domain Naming System 
10 (DNS) protocol. 

Time Service Provides global synchronization of time in the gaming 

network. This may be implemented by running the 
Network Time Protocol (NTP) client software on gaming 
machines. 

15 In addition to or instead of the core services described above, some embodiments 

o£the invention include one or more of the following services referred to as Basic Gaming 
Services: 



Accounting Service 



20 Event Management Service 
Game Update Service 



Message Director Service 



Content Integrity Service 



Provides logging of transaction records for billing and 
general tracking purposes. 

Logs events occurring at client and server machines. 

Provides dynamic distribution of new or updated game 
content to gaming machines. 

This service uses a software-configurable message 
routing application to facilitate the reliable exchange of 
data messages among multiple application processes 
within one or more gaming systems. 

This service provides the ability to verify the integrity of 
software components running in the gaming network. 
This includes the verification of software versions 
running on gaming machines, peripherals, services as 
well the detection of tampering or modification of the 
software. 
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15 



As noted above, a gaming service network may include Value Add Services. 
These services include participation services and player services. Examples of 
participation services that may be included in various embodiments of the invention 
include the following: ' 
Progressive Service 



Wide Area Disruption Progressive Service 



Mobile Gaming Device GPS Service 



Provides functionality for a gaming machine 
to participate within a single progressive or 
multiple progressives. 

This service takes over the processing of 
wide area progressives at each gaming site in 
the event that there is no connection with a 
central system or the connection with the 
central system is temporarily disabled. 

This service processes the GPS location of 
gaming machines compared with coordinates 
of a gaming jurisdiction. Example: players 
can ride a bus and begin gambling on the bus 
when the bus crosses into the gaming 
jurisdiction. 



20 



Examples of Player Services that may be included in various embodiments of the 



invention include: 
Player Tracking Service 



25 



30 



Game Theme Location Service 



35 



This service provides the operator and player with 
standard player tracking applications such as monitoring 
card in / card out transactions to track play and award 
player points for play, providing targeted promotional 
compensation to specific players, publishing accoupt 
status to the player or operator, providing temporary 
gaming machine locking in order to hold the machine for 
the player for short periods of time, and providing 
operators and players an interface and capability for 
Responsible Gaming Initiatives. 

This service provides location information to clients 
regarding specific games, game themes or vendor 
brands. The service may publish the information by 
casino, by area, by city, by state, by region, by country, 
or by continent depending on the input parameters 
provided. An example would be to publish where all of 

9 
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Personalization Service 



10 Bonusing Service 



Game Service 



15 



Advertising Service 



20 



Property Service 



Language Translation Service 



25 



Cashless Gaming Service 



30 



the progressive games of a particular theme (e.g., 
"Monopoly Money") are located in a particular hotel 
(e.g., the Reno Hilton) in Reno, Nevada. 

This service provides the gaming player with a more 
personalized gaming environment. Example: the player 
could choose to see text in Chinese, could choose to be 
reminded of dinner reservation time, could customize 
machine graphics, or could have a portion of his coin in 
go to his football club's progressive. 

This service provides the ability for casinos to set up 
bonus games for a specific gaming machine, carousel of 
machines or one or more game themes. 

This service is a server-side process that provides the 
outcome of game play. This service maybe used to 
enable Internet/ online gaming. 

This service allows the operator to display advertising 
information to players in multimedia format as well as 
simple audio and graphic formats. 

This is a group of services that provides the ability for 
the property management company to integrate with 
gaming systems. It can provide interaction with 
functions such as hotel and restaurant reservations. 

This service provides a translation method for players on 
a networked gaming machine. It may provide 
translations for one or more languages for the game 
itself, some of the additional features found on the 
machine, or the entire feature set of the gaming machine. 

This service provides the means to allow financial 
transactions such as funds transfers and game play 
transactions to occur electronically in a distributed or 
centralized model from the gaming machine. 



35 Additional details on a cashless gaming service according to embodiments of the 

invention are provided below. 
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It should be noted that with the distributed architecture of the Gaming Service 
Network 210, the above-described services that reside on network servers are not limited 
to location and can reside anywhere the network supports. For example, it is desirable to 
consider security and network latency when locating services. 

FIG. 3 is a block diagram of a Gaming Services Framework 300 according to 
various embodiments of the invention. In some embodiments, the Gaming Services 
Framework 300 includes a set of protocols, XML schemas, and methods for providing 
gaming system functionality in a distributed, network-based architecture such as the 
network described above in FIG. 2. In order to participate in such network-based 
architectures, the participating machines are interconnected via public or private networks 
that may be wired or wireless networks. Further, devices performing service 
communication support a common services protocol stack such as the Gaming Services 
Protocol Stack that is further described below. 

* 

The Gaming Services Framework 300 provides for the interaction of several 
logical elements as depicted in FIG. 3. Logical elements represent the fundamental 
entities that interact to implement a service. In some embodiments, these logical elements 
include Service Requestor 302, Service Provider 304, and Discovery Agency 306. In 
general terms, the roles these elements play are as defined in Web Services Architecture - 
W3C Working (Draft 14 November 2002 and later versions). Further details on these 
elements are provided below. 

Logical elements may reside in a number of different physical devices as part of 
delivering any service. For example, a Service Provider 304 will typically reside in a slot 
accounting or player tracking system and the Service Requestor 302 will typically reside in 
a gaming machine. However, there may be scenarios where it would be advantageous or 
appropriate for the logical elements to reside in other physical devices. For example, in 
alternative embodiments a Service Requestor 302 may reside in a slot accounting system. 

Service Provider 304 comprises a platform that hosts access to a service 314. A 
service provider may also be referred to as a service execution environment or a service 
container. Its role in the client-server message exchange patterns is that of a server. 



11 



WO 2005/001651 



PCT7US2004/020149 



Service Requestor 302 comprises an application that is looking for and invoking or 
initiating an interaction with a service such as that provided by service provider 304. Its 
role in the client-server message exchange patterns is that of a client 312. 

Discovery Agency 306 comprises a searchable set of service descriptions where 

5 service providers 304 publish their service description(s) 324 and service location(s) 326. 
The service discovery agency 306 can be centralized or distributed. A discovery agency 
306 can support both patterns where service descriptions 322 are sent to discovery agency 
306 and patterns where the discovery agency 306 actively inspects public service 
providers 304 for service descriptions 322. Service requestors 302 may find services and 

10 obtain binding information (in the service descriptions 324) during development for static 
binding, or during execution for dynamic binding. In some embodiments, for example in 
statically bound service requestors, the service discovery agent may be an optional role in 
the framework architecture, as a service provider 304 can send the service description 322 
directly to service requestor 302. Likewise, service requestors 302 can obtain a service 

15 description 324 from other sources besides a discovery agency 306, such as a local file 
system, FTP site, URL, or WSDL document. 

FIG. 4 provides a block diagram of a Gaming Services Protocol Stack 400 
according to embodiments of the invention. In some embodiments, the protocol stack 
includes core layers that define basic services communication and transport, and are 

20 typically implemented uniformly. Higher layers that define strategic aspects of gaming 
processes are also described below. FIG. 4 illustrates both the widely implemented core 
layers and in addition illustrates the higher gaming services oriented layers of the protocol 
stack. 

Core Layers of the Gaming Services Protocol Stack 400 
25 In some embodiments, the gaming services framework utilizes common Internet 

protocols, which may include web services protocols. Although not specifically tied to any 
transport protocol, it is desirable to build the gaming services on ubiquitous Internet 
connectivity and infrastructure to ensure nearly universal reach and support. In some 
embodiments, gaming services will take advantage of Ethernet 405 or 406, Transmission 
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Control Protocol (TCP) 408, Internet Protocol (IP) 407, User Datagram Protocol (UDP) 

409, HyperText Transfer Protocol (HTTP) 410, HyperText Transfer Protocol 
Secure/Secure Socket Layer (HTTPS/SSL) 411, Lightweight Directory Access Protocol 
(LDAP) 412, Domain Naming System (DNS) 413, and Dynamic Host Configuration 

5 Protocol (DHCP) 414 layers in the protocol stack 400. Those of skill in the art will 
appreciate that other protocol layers performing equivalent functionality may be 
substituted for those described above and are within the scope of the present invention. 

In some embodiments, service request and response data are formatted using 
Extensible Markup Language (XML) 415. XML 415 is a widely accepted' format for 

10 exchanging data and its corresponding semantics. XML is a fundamental building block 
used in. layers above the Common Internet Protocols. In some embodiments, the Gaming 
Services Protocol Stack 400 incorporates this protocol in accordance with the World Wide 
Web Consortium (W3C) XML Working Group's XML specification. However, those of 
skill in the art will appreciate that other data exchange formats may be substituted for 

15 XML 415, and s;uch formats are within the scope of the present invention. 

In some embodiments of the invention, the gaming service protocol stack 400 
utilizes the Simple Object Access Protocol (SOAP) 416. SOAP 416 is a protocol for 
messaging and RPC (Remote Procedure Call) style communication between applications. 
SOAP is based on XML 415 and uses common Internet transport protocols like HTTP 410 

20 to carry data. SOAP 416 may be used to define a model to envelope request and response 
messages encoded in XML 415. SOAP 416 messaging can be used to exchange any kind 
of XML 415 information. SOAP 416 is used in some embodiments as the basic standard 
for carrying service requests/responses between service users and providers. SOAP 416 
has been submitted to the World Wide Web Consortium (W3C) standards body as 

25 recommendation documents (versions 1.1 and 1.2) and will likely emerge as "XML 

Protocol (XP).' 

Higher Layers of the Gam in g Services Protocol Stack 400 

In some embodiments, the gaming services protocol stack includes a Web Services 
Description Language (WSDL) 417 and a Universal Description, Discovery, and 

■ 
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Integration (UDDI) 418. WSDL 417 comprises a description of how to connect to a 
particular service. In some embodiments, WSDL 417 is based on XML. A WSDL 417 
description abstracts a particular service's various connection and messaging protocols 
into a high-level bundle and forms an element of the UDDI 418 directory's information. 

5 WSDL 417 is similar to CORBA or COM IDL in that WSDL 417 describes programmatic 
interfaces. WSDL 417 is typically independent of the underlying service implementation 
language or component model, and focuses on an abstract description. The Gaming 
Services Protocol Stack 400 incorporates this description in accordance with the World 
Wide Web Consortium (W3C) Web Services Description Language (WSDL) 1.1 - W3C 

10 Note 15 March 2001 and later versions. 

In some embodiments, UDDI 418 represents a set of protocols and a public 
directory for the registration and real-time lookup of services. UDDI 418 enables an entity 
such as a company to publish a description of available services to the registry, thereby 
announcing itself as a service provider. Service users can send requests conforming to the 

15 UDDI 418 schema as SOAP 416 messages to the service registry to discover a provider 
for services. Some embodiments of the present invention may utilize UDDI Version 3, 
released in July of 2002 and later versions. Further development of UDDI 418 is managed 
under the auspices of the OASIS (Organization for the Advancement of Structured 

I 

Information Standards) UDDI Specifications technical committee. 

20 Returning to FIG. 3, the service requestors and service providers use the above- 

described protocol stack to perform service interactions with one another. The service 
interactions include publish 330, discover (find) 332, and interact 334. 

Publish interaction 330 provides a mechanism for a service to be' made accessible 
by other entities in the gaming network environment. In order to be accessible, a service 

25 needs to publish its description such that the requestor can subsequently find it. Where it is 
published can vary depending upon the requirements of the application. A service 
description 322 can be published using a variety of mechanisms known in the art. The 
various mechanisms used by the varying embodiments of the invention provide different 
capabilities depending on how dynamic the application using the service is intended to be. 
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The service description may be published to multiple service registries using several 

different mechanisms. The simplest case is a direct publish. A direct publish means the 
service provider sends the service description directly to the service requestor. In this case 

* 

the service requestor may maintain a local copy of the service description 322. 

5 Another means of publishing service descriptions utilized in alternative 

embodiments of the invention is through a UDDI registry. There are several types of 
UDDI registries known in the art that may be used depending on the scope of the domain 
of Web services published to it. When publishing a Web service description to a UDDI 
registry, it is desirable to consider the business context and taxonomies in order for the 

10 service to be found by its potential service consumers. Examples of UDDI registries used 
in the gaming service architecture of various embodiments of the invention are Internal 
Enterprise Application UDDI registry, Portal UDDI registry, and Partner Catalog UDDI 
registry. 

An Internal Enterprise Application UDDI registry may be used in some 
15 embodiments for gaming services intended for use within an organization for internal 
enterprise applications integration. For example, all services that provide gaming and 
gaming management to devices within a casino or casino organization may be published 
to an Internal Enterprise Application UDDI registry. 

A Portal UDDI registry may be used in some embodiments for gaming services 
20 that are published by a company for external partners to find and use. A portal UDDI 
registry typically runs in the service provider's environment outside of a firewall or in a 
DMZ (de-militarized zone) between firewalls. This kind of private UDDI registry 
generally contains only those service descriptions that a company wishes to provide to 
service requestors from external partners through a network. For example^ these services 
25 may be used to provide online gaming to customers connecting through the World-Wide 
Web. 

1 4 

A Partner Catalog UDDI registry may be used in some embodiments for gaming, 
services to be used by a particular company. The Partner Catalog UDDI registry can be 
thought of as a rolodex like UDDI registry. A Parmer Catalog UDDI registry is typically 

15 
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located on a computer or gaming machine behind a firewall. This kind of private UDDI 

registry typically contains approved, tested, and valid service descriptions from legitimate 
(e.g. authorized) business partners. The business context and metadata for these services 
can be targeted to the specific requestor. In some embodiments, this type of registry may 

5 be used for inter-casino services as well as interactions between casinos and other types of 
organizations such as regulators and financial institutions. It is desirable that an 
appropriate authorization and qualification procedure be in place to insure that only 
approved services are published to service repositories. 

In the discover interactions 332 (also referred to as find interactions), the service 

10 requestor retrieves a service description directly or queries the registry for the type of 

service required. It then processes the description in order to be able to bind and invoke it. 

As with publishing service descriptions, acquiring service descriptions may vary 
depending on how the service description is published and how dynamic the service 
application is meant to be. In some embodiments, service requestors may find Web 

1 5 services during two different phases of an application lifecycle - design time and run time. 
At design time, service requestors search for web service descriptions by the type of 
interface they support. At run time, service requestors search for a web service based on 
how they communicate or qualities of service advertised. 

With the direct publish approach noted above, the service requestor may cache the 

20 service description at design time for use at runtime. The service description may be 
statically represented in the program logic, stored in a file, or in a simple, local service 
description repository. 

Service requestors can retrieve a service description at design time or runtime from 
a Web page (URL), a service description repository, a simple service registry or a UDDI 

25 registry. The look-up mechanism typically supports a query mechanism that provides a 
find by type of interface capability (for example, based on a WSDL template), the binding 
information (i.e. protocols), properties (such as QOS parameters), the types of 
intermediaries required, the taxonomy of the service, business information, etc. 

16 



WO 2005/001651 PCT7US2004/020149 



The various types of UDDI registries, including those described above, have 
implications on the number of runtime binding services can choose from, policy for 
choosing one among many, or the amount of pre screening that will be done by the 
requestor before invoking the service. Service selection can be based on binding support, 
5 historical performance, quality of service classification, proximity, or load balancing. It is 
desirable that an appropriate authorization and qualification procedure be in place to , 
insure that only approved services are published to service repositories. 

Once a service description is acquired, the service requestor will need to process it 
in order to invoke the service. In some embodiments, the service requestor uses the service 
10 description to generate SCAP requests or programming language specific proxies to the 

service. The generation of such requests can be done at design time or at runtime to format 
an invocation to the service. Various tools can be used at design time or runtime to 
generate programming language bindings from interface descriptions, such as WSDL 
documents. These bindings present an API (Application Program Interface) to the 
15 application program and encapsulate the details of the messaging from the application. 

After a service has been published 330 and discovered 332, the service may be 
invoked so that a service requestor and service provider may interact 334. In the interact 
operation 334, the service requestor invokes or initiates an interaction with the service at 
runtime using the binding details in the service description 322 to locate, contact, and 
20 invoke the service. Examples of service interactions 334 include: single message one way, 
broadcast from requester to many services, a multi message conversation, or a business 
process. Any of these types of interactions can be synchronous or asynchronous requests. 

In some embodiments of the invention, security mechanisms may be used to secure 
the Gaming Services Framework 300. Securing the Gaming Services Framework typically 
25 involves providing facilities for ensuring the integrity and confidentiality of the messages 
and for ensuring that a service acts only on requests in messages that express the claims 
required by policies. Examples of such mechanisms used in various embodiments of the 
invention include IPSec and SSL/TLS, which provide network and transport layer security 
between two endpoints. However, when data is received and forwarded on by an 
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intermediary beyond the transport layer both the integrity of data and any security 

> 

information that flows with it maybe lost. This forces any upstream message processors to 
rely on the security evaluations made by previous intermediaries and to completely trust 
their handling of the content of messages. Thus it is desirable to include security 

5 mechanisms that provide end-to-end security. It is also desirable that such mechanisms be 
able to leverage both transport and application layer security mechanisms to provide a 
comprehensive suite of security capabilities. 

Cashless Gaming Service 
In general, the various embodiments of the invention implement a mechanism by 

10 which a player ir^ay conveniently use electronic fends transfers to wager at a gaming 
terminal. The funds transfers can be from the gaming terminal to a Cashless Gaming 
Service and frcm the Cashless Gaming Service to the gaming terminal. A player may 
initiate funds transfers while at a gaming machine. The casino can also initiate the transfer 
of promotional credits to a player's account. The Cashless Gaming Service provides the 

1 5 player with current account information, including the current balance and a list of 

transactions in the current period. The Cashless Gaming Service also supports inter-bank 
transfers between player accounts. For instance a player may request that funds be 
transferred from his/her Checking account to the Cashless Gaming account. 

A typical sequence of events is as follows. When a player signs up for a Player 

20 Tracking card or some other casino-issued identification, the player has the option of 

signing up for a Cashless Gaming account at the casino. The account can be operated just 
like a regular bank account and the casino in effect operates like a bank. The player can 
contribute funds to the account at the time the account is opened. Alternatively, the player 
may deposit funds later while actually playing at a Cashless Gaming Service-enabled 

25 gaming machine, akin to an ATM deposit. When a player identifies himself/herself to a 
Cashless Gaming Service-enabled gaming machine (via a Player Tracking card, User 
ID/PIN), the gaming machine sends a registration message with the player's identification 
and authorization information to the Cashless Gaming Service. If the player has previously 
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established an account, is in good standing and is eligible to use the Service, the Service 

will successfully register the player. 

The player may deposit funds at a gaming machine by inserting money into any of 
the gaming machine's cash-in devices. These funds are automatically transferred to his/her 
5 Cashless Gaming account, so that he/she might play with these funds at another gaming 
terminal in the future. When the player is done playing at a terminal, he/she has the option 
of cashing out all or a portion of the funds at the machine or committing them back to the 
Cashless Gaming account. If the Player removes the Player Tracking card (or signs off the 
session) at any time, the gaming device will automatically transfer all remaining credits in 

* 

10 the gaming machine back to the Cashless Gaming account. The player can at any time 
request the current account balance and a transaction history. 

The casino also has the ability to fund a player's account with promotional credits. 
These credits may be designated as cashable or non-cashable and are transferable between 
gaming machines- 

15 FIGs. 5 A, 5B and 6 are flow diagrams illustrating methods for providing a cashless 

gaming service in a gaming network according to embodiments of the invention. The 

( methods may be performed within an operating environment such as that described above 
with reference to FIGs. 1-4. The methods to be performed by the operating environment 
constitute computer programs made up of computer-executable instructions. Describing 

20 the methods by reference to a flow diagram enables one skilled in the art to develop such 
programs including such instructions to carry out the methods on suitable computers (the 
processor of the computer executing the instructions from machine-readable media such as 
RAM, ROM, CD-ROM, DVD-ROM, flash memory etc.). The methods illustrated in 
FIGs. 5A, 5B and 6 are inclusive of the acts performed by an operating environment 

25 executing an exemplary embodiment of the invention. 

FIG. 5 A is a flow diagram illustrating a method for providing a cashless gaming 
service in a service-oriented gaming network. In the detailed description of the method 
below, particular program method names may be provided for particular embodiments of 
the invention. It should be noted that such names are convenient labels for the method and 
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are exemplary in nature. The present invention is not limited to any functionality that may 

be implied by the name. 

The method begins by publishing the availability of a cashless gaming service on a 
gaming network (block 510). In some embodiments, the service is registered by sending a 
5 description (e.g. in WSDL) cf the service to the discovery agency. The discovery agency 
adds the service description to its UDDI repository. At this point the cashless gaming 
service is available for discovery by interested parties. 

Next, in some embodiments, a client/service requestor makes UDDI calls to the 
discovery agency to find a cashless gaming service (block 512). The discovery agency 
10 returns the service description and location information to the requestor. 

Next, a client/service requestor registers with the service provider (block 514). Jn 
some embodiments, this is accomplished by invoking a invoking a 

casWessGamingServiceRegister method on the Cashless Gaming Service. As an example, 
this may occur when a player inserts his/her Player identification card into the gaming 

15 terminal. In some embodiments this method call is a SOAP call and includes parameters 
that identify the gaming terminal, the player and provide authentication information to the 
Cashless Gaming Service provider. The Cashless Gaining Service provider may verify 
that the gaming terminal and player are authorized to execute methods in its service before 
successfully registering the client. When the client is done using the service, it may invoke 

20 a cashlessGamingServiceDeregister method on the Cashless Gaming Service. For 

example, this may occur when the player removes the Player identification card from the 
gaming terminal. 

Finally, a client ( e.g. a gaming terminal, a service requestor or a service provider) 
can invoke the cashless service to process a request (block 516). In some embodiments, 
25 invoking the cashless gaming service involves invoking methods. The methods may be 

either a SOAP message or an HTTP Request encapsulating an OFX message, or one based 
on a number of other open XML-based protocols such as IFX, IOTP, and ECML. The 
Cashless Gaming Service may implement ACH, SWIFT or any of a number of other 
electronic funds transfer protocols to transact with other financial institutions. 
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The Open Financial Exchange (OFX) is a standardized, extensible XML-based 

protocol to exchange information between clients and financial institutions. OFX supports 
message sets for Consumer Banking operations, inter-bank transfers, wire transfers, 
recurring transfers, credit card, automatic payment processing, taxes and brokerage 
5 investments. In a casino gaming environment, the Consumer banking message set 
adequately encapsulates the needed functionality to perform electronic funds transfers. 

The Interactive Financial eXchange (IFX) is another XML-based, financial 
messaging protocol. IFX provides content rich conversations in the areas of Electronic 
Bill Presentment and Payment, Business to Business Payments, Business to Business 
10 Banking, Automated Teller Machine communications, Consumer to Business Payments 
and Consumer to Business Banking. 

The Internet Open Trading Protocol (IOTP) is an interoperable framework for 
Internet commerce. It is optimized for the case where the buyer and the merchant do not 
have a prior acquaintance and is payment system independent. 
15 The Electronic Commerce Modeling Language (ECML) defines a standard set of 

information fields used by consumers in electronic commerce transaction, so that the task 
of filling in the fields can be automated by wallet software, for example. 

The choice of a cashless transfer protocol will depend on the model of the cashless 
network, hi the first model, the gaming machine and the server collaborate in financial 
20 bookkeeping. In this model the gaming machine must handle bookkeeping for the money 
on resident on the gaming machine while the server handles the bookkeeping for the 
money resident in the Cashless Gaming account. Money is transferred electronically 
between the server and the gaming machine. This model will be referred to as the 
Distributed Banking model. 
25 In the second model, all accounts are maintained at the server and the server 

handles all financial bookkeeping. The gaming machine simply displays the current 
account information held at the server. This will be referred to as the Centralized Banking 
model. The OFX (or IFX) protocol may be more appropriate in this model between the 
gaming machine and the Cashless Gaming Service. Money transfers occur on the server 
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between the Player's account and the Casino's account. The gaming machine is only 
responsible for displaying the Player's current account balance as well as translating game 
outcomes to OFX (or IFX) transactions that axe sent to the server to fulfill. The OFX (or 
IFX) protocol may also be used to request the transfer funds between the Player's Cashless 

5 account and zv, external account held at another financial institution. OFX (or IFX) also 
allows the client to query the Cashless service for a list of transactions for a given period. 

The following is a nonexclusive list of methods of the cashless gaming service 
that may be invoked in various embodiments (the methods may be implemented as SOAP 
calls): 

10 cashlessGamingServiceNewAccount - The client makes this call to the Cashless Gaining 

Service to establish a new account for the Player. In some 
embodiments, only the casino's management system will have 
the authority to make this request. 

■ 

casUessGamingServiceModifyAccount - The client makes this call to the Cashless 
1 5 Gaming Service to modify the details of an existing account. In 

some embodiments, only the casino's management system will 
have the authority to make this request. 

casMessGamingServiceCloseAccount — The client makes this call to the Cashless Gaming 

Service to close out an existing account. In some embodiments, 
20 only the casino's management system will have the authority to 

make this request. 

cashlessGamingServiceGetAccountDetails - The client makes this call to the Cashless 

Gaming Service to get detailed information about the Account. 
The account information may include name, address, phone 
25 number, tax identification number, account number, account 

balance, promotional credits balance and transaction history. 

cashlessGamingServiceGetAccountBalance - The client makes this call to the Cashless 

Gaming Service to get the current account balance. 

cashlessGamingServiceGetTransactioiiHistory - The client makes this call to the Cashless 
30 Gaming Service to get a list of account transactions for the 

specified period. The extent of account history retained by the 
Cashless Service is implementation dependent. Players may 
retrieve the transaction history of their account while at a 
gaming terminal. Players may optionally choose to print it out 
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on the gaming machine's printing device or have it sent to a 
chosen email address for later viewing. 

cashlessGamingServiceDepositFunds - The client makes this call to the Cashless Gaming 

Service to deposit funds to the account. Typically the player 
5 situated at a gaming terminal initiates this action. 

cashlessGamingServiceWithdrawFunds - The client makes this call to withdraw funds 

from the Cashless Account and transfer them as playable credits 
on the gaming terminal where the player is situated. 

cashlessGamingServiceTransferFunds - The client can make this call to request a fluids 
10 transfer between a player's external account (e.g. Checking 

account) and his/her Cashless Gaming account. The gaming 
fciiLLisl will obtak. authorization information from the player 
prior to requesting the funds transfer. This call may also be used 
to transfer funds between two Cashless Gaming accounts that 
15 have been previously set up as linked. For example a player may 

transfer funds to a spouse's account directly from a gaming 
machine. As another example, a player can tip the wait-staff 
directly by transferring funds to the wait-stafPs account at the 
gaming terminal. 

20 cashlessGamingServiceDepositPromoCredits - The client makes this call to request to 

deposit promotional credits to the players account. The casino 
operator will typically initiate this operation. 

cashlessGamingServiceWithdrawPromoCredits - The client makes this call to request to 

withdraw promotional credits from the players account. The 
25 casino operator will typically initiate this operation. 



FIG. 5B illustrates a method according to an embodiment of the invention for 
providing a cashless gaming service to a client in a gaming machine network. In 
particular, FIG. 5B illustrates an exemplary usage scenario involving an exemplary 
30 message sequence 500 that describes how a client such as gaming machine 501 and a 
cashless gaming service 502 interact between themselves and other components of a 
gaming network such as discovery service 503 and an authorization database 504 when a 
player deposits funds to a Cashless Gaming account. Message sequence 500 is but one 
example of a message sequence. Those of skill in the art will appreciate that other 
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message sequences for other types of requests are within the scope of the invention. 
Additional information for each message is provided below as defined by the reference 

number in FIG. 5B. 

At 521 the Cashless Gaming Service 502 is deployed and saves its binding 
5 information to the Discovery Service 503 (e.g. using a UDDI Registry). 

At 522 the Discovery Service 503 authenticates the Cashless Gaming Service 502 
with the Authentication/Authorization/ Account Database 504 (e.g. using LDAP, RADIUS, 
SQLServer, Oracle, et al.). 

At 523 the Authentication/Authorization/ Account Database 504 successfully 
10 authenticates the Cashless Gaming Service 502 (e.g. using LDAP, RADIUS, SQLServer, 
Oracle, et al.). 

At 524 the Discovery Service 503 returns a bindingDetail information element to 
the Cashless Gaming Service 502 (e.g. using UDDI). The Cashless Gaming Service 502 i? 
now ready to accept requests for service from clients (e.g. gaming machines, game servers 
15 or other components of a gaming network). 

At 525 a Gaming Machine 501 contacts the Discovery Service 503 to find the 
location of a Cashless Gaming Service (e.g. using UDDI). 

At 526 the Discovery Service 503 returns with a list of possible Cashless Gaming 
Services (e.g. using UDDI). 

20 At 527 the Gaming Machine 501 chooses one (using some suitable algorithm) and 

requests the binding information of that instance of the Cashless Gaming Service 502 (e.g. 
using UDDI). 

At 528 the Discovery Service 502 returns the binding information to the Gaming 
Machine 501 (e.g. using UDDI). 

25 At 529 a player inserts a player-tracking (or other ID) card into the Gaming 

Machine 501. 
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At 530 the Gaming Machine 501 registers with the Cashless Gaming Service 502 
(e.g. using SOAP) on behalf of the player. 

At 531 the Cashless Gaming Service 502 authenticates the Gaining Machine 501 
and player with the Authentication/Authorization/Account Database 504 (e.g. using 
5 LDAP, SQLServer, Oracle, et al). 

At 532 the Authentication/Authorization/ Account Database 504 successfully 
authenticates the Gaming I^achine 501 and player (e.g. using LDAP, RADIUS, 
SQLServer, Oracle, et al.). 

At 533 the Cashless Gaming Service 5C2 retinas a successful respor^ , iz €ic 
10 Gaming Machine 501 (e.g. using SOAP). 

At 534 the player inserts funds, plays the game for a period of time and upon 
completing play, removes the player-tracking card while there are still credits remaining 
on the Gaming Machine 501. The player selects the option of depositing the credit balance 
back to the player's cashless account. 

15 At 535 the Gaming Machine 501 sends a cashlessGamingServiceDepositFunds 

message (SOAP) to the Cashless Gaming Service 502. The message contains at a 
minimum the Player ID, Date/Time, deposit amount (credit balance) and a unique 
transaction ID. 

At 536 the Cashless Gaming Service 502 commits those funds to the player's 
20 account by sending a DEPOSIT JFUNDS_REQ message to the Account Database 504 
(e.g. using LDAP, RADIUS, SQLServer, Oracle, et al.) 

* 

At 537 the Account Database 504 successfully acknowledges completion of the 
transaction by returning a DEPOSIT JFUNDS_RSP (e.g. using LDAP, RADIUS, 
SQLServer, Oracle, et al.) to the Cashless Gaming Service 502. 

25 At 538 the Cashless Gaming Service 502 responds to the Gaming Machine 501 

with a cashlessGamingServiceDepositFundsAck message (SOAP). Either or both of the 
Gaming Machine 501 and the Cashless Gaming Service 502 may maintain a transaction 

25 



WO 2005/001651 



PCT/US2004/020149 



log for audtf purposes and also to re-sync their databases in the event of lost 
communication. 

FIG. 6 illustrates a method according to an embodiment of the invention for 
providing a cashless gaming service to a client in a gaming machine network. In 
5 particular, FIG. 6 describes an exemplary message sequence scenario 600 of how a player 
transfers funds between an external Checking Account and the Cashless Gaming account. 
Message sequence 600 is but one example of a message sequence. Those of skill in the art 
will appreciate that other message sequences for other types of requests are within the 
scope of the inventive subject matter. Additional information for each message is 
10 provided below as defined by the ID number in FIG. 6. Note that the discovery process is 
omitted from this sequence. It is assumed that the gaming machine knows how to locate 
the Cashless Gaming Service (OFX server.) 

At 621 the player inserts a player-tracking card into the Gaming Machine 601 and 
initiates a funds transfer from an external Financial Institution account to the Cashless 
15 Gaming account The player enters via a keypad, touch screen, or some other interface 
identification and authorization information for the account(s) being used. 

At 622 the Gaming Machine 501 then sends on behalf of the player a message to 
the Cashless Service 602. In some embodiments, the message is an OFX message carried 
in an HTTP POST Request message. The message is transmitted securely using SSL 
20 (Secure Sockets Layer) and contains a Sign-on section, a transaction section, a Destination 
Acct section, a Source Account Section, a transaction amount, and a fulfillment date (IFX 
can also be used). 

At 623 the Cashless Service 602 authenticates the player and source account 
information with the Authentication/ Authorization/ Account Database 603 (LDAP, 
25 SQLServer, Oracle, et al.) 
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At 624 the Authentication/Authorization/Accoxint Database 603 successfully 
authenticates the player and source account information (LDAP, SQLServer, Oracle, et 
al.). 

At 625 the Cashless Service 602 then initiates an inter-bank transfer using any 

5 standard electronic funds transfer network such as SWIFT, ACH or FedWire with the 
player's Financial Institution External Account 604. 

At 626 the Financial Institution 604 acknowledges and completes the transfer 
transaction. 

A: 627 thr, Casftlcas Service 602 cc:.:.ra:tG the funds to the Cashless Gaming 
10 Account 603 (LDAP, SQLServer, Oracle, et al.) 

At 628 the Cashless Gaming Account 603 successfully acknowledges completion 
of the transaction (LDAP, SQLServer, Oracle, et al.) 

At 629 the Cashless Service 602 responds to the Gaming Machine 601 with an 
OFX message contained in an HTTP OK Response. 

15 At 630 the player can now view the deposited funds on the Gaming Machine 601 

and display and wager those funds directly out of the Cashless Gaming Account 603. This 
implies that every game play results in a transaction to the Cashless Service 602. In the 

case of a win the Gaming Machine will request a transfer from the Casino's accoimt to the 

i • 
player's Cashless Gsxf Accrr-n* 603. In the case of a loss, the machine will request a . 

20 transfer from the player's Cashiers Gzmmg Account 603 to the Casino's account. 

i 

Conclusion 

Systems and methods providing a cashless gaming service in a service- 
oriented gaming network environment have been disclosed. Although specific 
embodiments have been illustrated and described herein, it will be appreciated by 
25 those of ordinary skill in the art that any arrangement which is calculated to achieve 
the same purpose may be substituted for the specific embodiments shown. This 
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application is intended to cover any adaptations or variations of the present 
invention. 

The terminology used in this application is meant to include all of these 
environments. It is to be understood that the above description is intended to be 
5 illustrative, and not restrictive. Many other embodiments will be apparent to those 
of skill in the art upon reviewing the above description. Therefore, it is manifestly 
intended that this invention be limited only by the following claims and equivalents 
thereof. 
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